Modular control systems, used today in a variety of industries, are complete control systems that can provide specific functionality, such as boiling water, filtering liquids, or controlling heat exchange. A modular control system typically is implemented as a skid-mounted system, or simply “skid,” so called because the system is enclosed within a frame and is easily transported. A skid can be delivered to a factory as an integral unit, without being disassembled and reassembled, and typically preconfigured by the manufacturer. A skid generally includes a programmable logic controller (PLC), specialized equipment such as valves or boilers, and sensors such as pressure or temperature sensors, for example.
On the other hand, distributed control systems (DCS) also are used in a variety of process industries including chemical, petrochemical, refining, pharmaceutical, food and beverage, power, cement, water and wastewater, oil and gas, pulp and paper, and steel, and are used to control batch, fed-batch, and continuous processes operating at a single site or at remote locations. Process plants typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog/digital buses, or via a wireless communication link or network. Collectively, the various devices perform monitoring, control, and data collection functions to control the process, safety shutdown systems, fire and gas detection systems, machine health monitoring systems, maintenance systems, decision support, and other systems.
The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process parameters, etc. to control one or more processes executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known Fieldbus protocol may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules which make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant or system.
Information from the field devices and the controller is usually made available over a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or other locations away from the harsher plant environment. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run applications that may, for example, enable an operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.
As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more workstations or computing devices, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration engineer to create or to change operator interfaces, which are used by a viewing application to display data to an operator, and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
Devices operating in process control and industrial automation systems can be interconnected in a wired or wireless manner, and communicate using industrial communication protocols such as FOUNDATION™ Fieldbus, HART®, or Profibus. Further, protocols such as Modbus have been developed to interconnect PLCs. Still further, in addition to standard industrial automation protocols there exist proprietary protocols for interconnecting nodes in a process control system. DeltaV is an example of one such protocol. In general, these protocols specify formats for conveying measurements, alerts and status reports, commands that affect process variables or automation parameters, commands for activating or deactivating devices, etc. A typical industrial communication protocol also supports device configuration, via pre-defined commands or commands defined by manufacturers for specific devices in accordance with the syntax of the protocol.
While using skids equipped with PLCs is a popular approach to building a process control plant, PLCs today cannot be integrated natively into a large DCS. PLCs generally rely on proprietary protocols, configuration, and security. At best, operators can use weak integration via Modbus or some other standard protocol to bring PLCs into a larger system. Weak integration is a manual process that does not withstand certain types of changes and requires manual maintenance as the system evolves.
In addition, PLCs may experience configuration limitations because PLCs typically have limited, or difficult to manage, port configuration options. For example, a PLC's configuration limitations can be attributable to a PLC's communication ports limitations or inability to communicate with other nodes of a process plant via a network or data highway of the process plant. For example, a typical PLC may include dedicated communication ports that allow only certain types of protocols, such that other nodes in the process plant, communicating using different protocols, would not be able to connect to the PLC via the dedicated ports. The dedicated ports are especially problematic where the PLC has few or a limited number of communication ports. For example, a PLC providing a single dedicated port for each of a variety of communication protocols (e.g., one port for Modbus, another port for Ethernet, etc.) may inhibit the PLC from retransmitting communications from one port to another port, e.g., because of the different and incompatible communication protocols.
Limited communication ports may also cause problems when a PLC needs to communicate, e.g., receive instructions from and/or provide data to, multiple nodes using the same type of communication protocol, but where the PLC does not have enough communication ports to accommodate all of the nodes of that particular type of communication protocol. In such situations, the PLC would need to utilize multiple external switches to accommodate the additional nodes of the particular communication protocol, which would increase the complexity and costs associated with the distributed process control system of the process plant.
Moreover, in instances where isolation is desired for security reasons, for example, to prohibit certain nodes of the distributed control system from communicating with other nodes via the PLC, then the limited configuration options of the PLC's communication ports creates additional problems. For example, in such instances, the PLC may have limited or no means to control the retransmission of communications (e.g., data packets or messages) to other ports of the PLC. This can lead to security issues where an operator of a skid may desire to prevent certain ports of the PLC from communicating with other ports associated with the PLC in order to control secure access among the nodes connected PLC. In such instances, the skid operator may be forced to add external firewalls to the PLC in order to implement secure access among the nodes connected to the PLC, which would create increased complexity and costs associated with the distributed process control system of the process plant. In addition, such configurations would require additional programmatic and settings configurations to the PLC by the operator, which can be complex, and which can be burdensome because the skid operator would typically have to manually implement such programmatic and settings configuration changes each time the configuration of the PLC changes, for example, each time the nodes and/or communication protocols that are connected to and/or used with the PLC changes.